1. Field of the Invention
The present disclosure generally relates to systems and techniques for testing semiconductor devices in the form of hardware and/or software representations, and, more particularly, to systems and techniques for testing complex integrated circuits that include a central processing unit (CPU) and embedded peripheral devices connected to the CPU by internal bus systems to define a system on chip (SoC).
2. Description of the Related Art
In manufacturing semiconductor devices including a relatively complex circuitry, the testing of the device may represent a part of the manufacturing process, which has been underestimated a long time in terms of cost and effort required to obtain reliable data with respect to proper functionality and reliability of the device. In this respect, the manufacturing of the complex semiconductor device is to be understood to include the design of the device on the basis of a functional description of the desired functional behavior of the device, the various stages of providing a preliminary representation of the device in the form of a software model or a hardware prototype and respective re-designed versions thereof after encountering failures during verification, as well as the actual implementation of the finally established design in the semiconductor material. Thus, one reason in failing to meet specifications of the integrated circuit with respect to functional behavior may reside in design errors that may be identified and remedied by circuit verification on the basis of software simulation and/or prototype testing prior to mass production of the integrated circuits under consideration. An improper functionality of the integrated circuit may further be caused by the manufacturing process itself when the completed circuitry does not correspond to the verified circuit design, owing to process fluctuations in one or more of the large number of process steps involved during the processing. Although measurement and test procedures are incorporated at many points in the manufacturing process, it is nevertheless extremely important to ascertain the correct functioning of the final semiconductor device, since, according to a common rule of thumb, the costs caused by defective chips increase with each assembly phase by approximately one order of magnitude. For example, the costs caused by a defective circuit board including a faulty chip are typically significantly higher than identifying a defective chip prior to shipping and assembling the circuit board. The same holds true for a system, when a failure thereof is caused by one or more defective circuit boards as a downtime of an industrial system may result in averaged costs of approximately several hundred dollars per minute compared to a price of a few dollars for an integrated circuit chip having caused the defect.
Hence, there is a vital interest in developing test procedures to identify as many defects as possible in completed integrated circuits while not unduly increasing the total manufacturing costs. In particular, with the demand for more features and lower costs of circuits, there is a tendency to integrate a plurality of different circuit portions into a single chip to provide a complete system on a chip (SoC). A semiconductor device comprising various functional blocks may typically include, in addition to one or more logic blocks, one or more embedded memory portions, such as are used as on-chip cache for CPUs or as buffers for data packets that are transferred between different clock domains, and other peripheral components, such as complex I/O devices, dedicated functional blocks for efficient data processing of a specific type and the like, wherein these peripheral blocks are operatively connected to the CPU of the system via appropriate bus systems.
As discussed above, economic constraints force semiconductor manufacturers to not only minimize the defect level of the total manufacturing process, but also to provide, in combination with a reduced defect level, a high fault coverage so as to reduce the delivery of defective chips at reasonable cost for appropriate test procedures and techniques. For moderately complex integrated circuits, it has become standard practice to develop the basic design of the circuit while taking into consideration a plurality of constraints posed by effective test procedures. Moreover, typically, additional hardware resources are provided in the chip that may enable the identification of faulty circuit components for a broad class of operating conditions, wherein the additional hardware resources in combination with design specifics of the basic circuit and sophisticated test procedures and test patterns substantially determine the fault coverage of the test procedure.
In many circuit designs, the functional logic portion is tested by so-called scan chains, which represent a chain of flip-flops connected to a specific area of the functional logic in such a way that the functional logic or a specific area thereof may be initialized with a desired state that has previously been entered into the scan chain. In this case, the state of the logic block may be verified on the basis of the state of individual logic gates, which may be considered as a verification of the operational behavior of the logic block at register transfer level. However, with the advance of the semiconductor technology having arrived at transistor dimensions as low as approximately 40 nm and less, highly complex CPU designs are available including millions of logic gates, which makes it increasingly difficult to verify the proper functionality of the CPU at the register transfer level. Moreover, due to the incorporation of complex peripheral blocks, as explained above, additional efforts are required for identifying design flaws at an early manufacturing state prior to actually implementing mass production techniques.
Hence, the changing focus in the electronic industry from frequency scaling to enhancement with respect to functionality may contribute significantly to the overall complexity of the corresponding verification of semiconductor devices, thereby generating an increased demand for verification techniques that enable the testing of circuit designs at higher levels of abstractions compared to the registered transfer level, previously explained. For example, the verification complexity for register-based logic circuits rises as the square of the increase in the number of registers and thus by doubling the complexity of circuit implementation, for instance by advancing from one technology node to a future node, a four-fold impact on verification may result. In order to enable an efficient modeling of highly complex circuit designs of embedded hardware/software systems for estimating functional characteristics and performance behavior prior to the actual implementation of these systems, a plurality of different system description languages, such as SystemC, SpecC, System Verilog and the like, have been developed. However, in addition to providing appropriate and powerful description languages for modeling complex circuit designs, the verification may be performed on different abstraction levels to provide the possibility of reducing verification costs and allowing identification of design flaws and associating the same with deficiencies in architectural aspects or implementation-specific aspects. The modeling of complex circuit designs on a higher abstraction level compared to the register transfer level may, for instance, be accomplished by a transaction-based modeling technique that is based on combining various communication events to so-called transactions, thereby achieving a significantly higher degree of abstraction compared to the register transfer level of usual signals. That is, a transaction may be understood as a complete communication event, for instance, the transmission of a date or of a complete block of data wherein a respective communication event is ideally represented by the exchange of a single message within the transaction-based simulation model. In this way, enhanced simulation performance may be obtained compared to event-controlled simulation of signal-based communication protocols. The abstraction obtained by the transaction-based modeling technique may be associated with a reduced accuracy with respect to the timing within the simulated circuit since the various different protocol phases, which may be required during a respective transaction, may not be resolved, wherein, even for commonly used communication media, such as interface buses, a reduced degree of accuracy may result. That is, the timing for completing transactions may be monitored with a different degree of accuracy, depending on the modeling strategy used. For instance, cycle approximate models typically implement respective transactions such that the simulated time interval of activity may be closely related to the respective time required in an actual hardware implementation. However, precise resolving of the progression of different transactions may not be monitored and also the total duration of a single transaction, that is, active phases plus interruptions, may not be determined from the model. On the other hand, the total communication traffic on a respective bus may be determined with a sufficient accuracy. Consequently, by using a transaction-based verification, the estimation and testing of certain circuit components may be accomplished on a higher level compared to the level of bus signal changes, thereby enhancing the overall verification efficiency. For instance, transactions may typically be generated randomly so as to increase test coverage, while also providing the possibility of introducing specific constraints in order to exclude useless operational scenarios in the circuit component under test.
Conventional verification approaches for complex systems containing a central processing unit (CPU) usually split verification into verification of the CPU core and verification of the embedded peripheral functional components. After the verification of these components, an additional step of system verification may be performed to estimate and verify the functional behavior of the system as a whole.
With reference to FIGS. 1a-1c, a typical conventional approach for performing a verification process for a system on chip may be explained, wherein different levels of abstraction may be used.
FIG. 1a schematically illustrates a system 100 representing a complex semiconductor device in a respective state of the overall manufacturing process flow. That is, the system 100 may represent a semiconductor device at design state comprised of various functional modules, while one or more of the components of the system 100 may also be provided in the form of hardware-implemented prototypes, if deemed appropriate. For instance, the system 100 may comprise a central processing unit (CPU) 101, a peripheral functional block 102 and a memory controller 103, wherein these components may communicate with each other by a corresponding bus or interface system, which may be referred to as a crossbar switch (xbar) 105. As indicated above, the verification of the CPU 101 may be substantially based on assembly code generators which provide an assembly code in a more or less random manner while also including specific constraints in order to avoid inefficient phases during the verification of the CPU 101. The assembly code may then be translated into machine code that is supplied to the CPU 101 and also to a reference model so as to compare the results created by the assembly code in the CPU 101 and the reference model.
FIG. 1b schematically illustrates a test environment 150, which may also be referred to as a test bench that is configured to perform the above-described verification sequence. That is, the test environment 150 comprises a test case or test controller 151 connected to an assembler generator 152 for providing a randomized sequence of assembly structure which may optionally be controlled by the test case 151. Moreover, a module 153 representing respective verification constraints may be connected to the assembler generator 152 to incorporate specific limitations with respect to the randomness of the assembler code provided by the generator 152. Furthermore, a machine code converter 154 is connected to the assembler generator 152 in order to generate machine code on the basis of the input assembler code. As shown, the test case 151 may also be connected to the machine code converter 154 when predetermined test scenarios in the form of appropriately preselected assembler instruction sequences are to be used during the verification of the CPU 101. The machine code output by the machine code converter 154 may be stored in an appropriate memory device or memory model 155, from which the CPU 101 and an appropriate reference model 156 may retrieve machine code instructions executed by the CPU 101 and the reference model 156. The results obtained from the CPU 101 and the reference model 156 may be supplied to a check module 157, which may basically compare respective results and indicate any deviations in order to identify faults in the CPU 101.
FIG. 1c schematically illustrates a test environment 160 in the form of a transaction-based environment, which may be used for verification of the peripheral functional block 102, which may actually comprise a plurality of embedded peripheral components, as explained above. Thus, the test environment 160 is configured to stimulate the peripheral functional block on a higher level of abstraction, as previously explained, wherein respective transactions usually represent a plurality of protocol entities of the various bus interfaces in the system required for the operation of the peripheral functional block 102 within the system 100. For this purpose, the test environment 160 comprises a test case or controller 161 configured to control a transaction generator 162 so as to provide a sequence of transactions in order to obtain a desired high degree of test coverage. For instance, the test case 161 may control the transaction generator 162 to provide a more or less random stream of transactions, while specific limitations or constraints may also be imposed on the transaction generator 162 in order to avoid inefficient test scenarios. The transactions created by the generator 162 may be translated into appropriate signal waveforms for a bus, such as bus A connected to the peripheral functional block 102. The translation of transactions into appropriate bus signals may be accomplished by a bus functional model (BFM) 163 wherein, however, as previously explained, the time coordination of the transactions and the respective bus signal waveforms may depend on the underlying modeling strategy. The peripheral functional block 102 responds to transactions by respective signal waveforms provided on a respective bus interface B which in turn is connected to a monitor 164 that is configured to convert the bus signals into transactions. Similarly, the bus signals of bus A may be supplied to a monitor 165 which may convert the bus signals into transactions which may then be forwarded to a reference model 166 representing the expected behavior of the peripheral block 102.
In other cases, the monitor 165 may be omitted and the reference model 166 may be directly connected to the transaction generator 162. The transactions provided by the monitor 164, representing the response of the peripheral functional block with respect to the initial transactions obtained from the generator 162, are forwarded to a check module 167, which also receives the initial transactions via the monitor 165 or the transaction generator 162. Thus, a respective deviation of results from the reference model 166 and the peripheral functional block 102 may be estimated on transaction level in order to verify the operational behavior of the block 102. Moreover, a feedback may be implemented between the monitor 164 and the test case 161, for instance via an appropriate test coverage module 168, or any other appropriate functional module, which may therefore enable the test case 161 to adapt the stream of transactions produced by the generator 162 in response to the transactions obtained from the monitor 164. Thus, the stimulating transactions obtained from the generator 162 may be adapted “on the fly” with respect to the response of the peripheral functional block 102. It should be appreciated that, depending on the configuration of the peripheral block 102, a plurality of respective monitors and check modules may be provided so as to allow the evaluation of a plurality of individual components within the peripheral functional block 102. Thus, a high degree of test coverage may be obtained, for instance, on the basis of randomized yet constrained transaction streams, with a significantly reduced amount of verification time compared to a scenario operating on a less abstract level.
As previously indicated, the system 100 may be tested as a whole which may be accomplished by running a set of directed test scenarios from inside the simulated CPU 101 in order to address the embedded peripheral functional block 102, which, however, may result in a compromised functional coverage or reduced implementation of resources due to the very restrictive directed test scenarios. In other cases, the system 100 may be modified compared to the configuration as shown in FIG. 1a so as to further comprise an interface for a bus functional model in order to inject transactions into the system 100, in which case the CPU 101 may not be involved in verification at system level.
The present disclosure is directed to various methods and systems that may avoid, or at least reduce, the effects of one or more of the problems identified above.